Node / ReticulumProjects / MeshChatX.git / files / SECURITY.md

Displaying Rendered • View raw • Download

If you discover a security vulnerability or have concerns about the security of Reticulum MeshChatX, please contact the lead developer using the following methods in order of preference:

1. LXMF: T3838387cc8d66b4f6a0e0e49d34af7f6077b5a

For legal inquiries (non-security), contact T383838legal@quad4.io or see LEGAL.md.

Reticulum MeshChatX is designed with a high degree of security and privacy in mind, leveraging multiple layers of protection and modern security practices.

We follow the Electron Best Security Practices.

MeshChatX is primarily intended for local or trusted networks (for example behind a home router or VPN). Putting the HTTP(S) UI on the public internet is not recommended: you enlarge the attack surface (credential stuffing, TLS and certificate management, reverse-proxy misconfiguration, automated scanning, and denial-of-service against the single-node service).

If you still choose to expose it, enable authentication, use HTTPS (valid certificates on the public name), restrict who can reach the port where possible (firewall allowlists, VPN, or a reverse proxy with additional controls), and keep the app updated. The application serves T383838/robots.txt with T383838Disallow: / (a hint to crawlers; it is not access control). The application includes defence-in-depth for the login and initial-setup endpoints: per-IP rate limiting, lockout after repeated failed passwords from an address (with trusted client recognition after a successful login so your own browsers are less likely to be blocked during broad attacks), logging of access attempts (IP, User-Agent, path, time) inspectable under Debug Logs → Access attempts, and session cookies configured as HttpOnly with SameSite=Lax. None of this removes the inherent risks of a public-facing service; it only reduces some abuse and accident scenarios.

• ASAR Integrity Validation: Utilizes Electron 39 features to protect the application against tampering.

• Backend Binary Verification: Generates a SHA-256 manifest of the unpacked Python backend during build and verifies it on every startup.

• Data-at-Rest Integrity Monitoring: Snapshots the state of identities and database files on clean shutdown and warns if they were modified while the app was closed.

• CSP Hardening: Multi-layered Content Security Policy protection across the entire application stack.

• Hardened Electron Environment: Hardened security by disabling T383838runAsNode and T383838nodeOptions environment variables via Electron Fuses.

• Rootless Docker Images: Support for running in restricted environments with rootless container images.

The project employs continuous security monitoring and testing:

• Security Scanning: T383838.gitea/workflows/scan.yml runs on a weekly schedule and on pushes to T383838master and T383838dev. It installs frontend dependencies and runs Trivy filesystem vulnerabilities on the repo (T383838scripts/ci/trivy-fs-scan.sh: high and critical severities, exit non-zero on findings), and Trivy Dockerfile misconfiguration (T383838trivy config --exit-code 1 Dockerfile). The Docker workflow runs Trivy on the built image (T383838trivy image) separately from that job.

• Auth and path-safety tests: Pytest covers HTTP 401 on protected T383838/api/* when T383838auth_enabled is on and no session (T383838tests/backend/test_notifications.py), ValueError on backup/snapshot delete paths that escape storage (T383838tests/backend/test_security_path_and_backup.py), and schema upgrade from version N-1 (T383838tests/backend/test_schema_migration_upgrade.py). Database backup/restore round-trips are covered in T383838tests/backend/test_database_snapshots.py. Login and setup rate limiting, lockout, and access attempt logging are covered in T383838tests/backend/test_access_attempts_dao.py and T383838tests/backend/test_access_attempts_enforcement.py (including Hypothesis and HTTP smoke tests).

• CI: On pushes and pull requests, T383838pip-audit (Python) and Trivy (T383838trivy fs via T383838scripts/ci/trivy-fs-scan.sh) run against the repository tree (including Node lockfiles and manifests after install where applicable).

• Pinned Actions: CI/CD workflows use pinned actions with full URLs to forked, vetted actions hosted on our Gitea instance (T383838git.quad4.io) where an action is used at all.

• Extensive Testing & Fuzzing: Backend benchmarking and stress coverage to reduce instability and resource-exhaustion risks.

• Linting & Code Quality: Linting and static analysis run on CI paths.

Tagged releases are built from T383838.gitea/workflows/build.yml. Release assets include SHA256 sidecars (T383838.sha256 files next to each file) and a CycloneDX SBOM (T383838sbom.cyclonedx.json). When the repository secret T383838COSIGN_PRIVATE_KEY is set (PEM from T383838cosign generate-key-pair, with T383838COSIGN_PASSWORD if the key is encrypted), the workflow also produces SLSA v1-style cosign bundle files (T383838*.cosign.bundle) next to each attested artifact.

Attestations are uploaded to the Sigstore public transparency log (Rekor) by default. The build runner must be able to reach the Rekor endpoint (default T383838https://rekor.sigstore.dev; override with T383838COSIGN_REKOR_URL if you use another instance).

Commit the cosign public key at the repository root as T383838cosign.pub so others can verify without hunting for the key out of band.

Rotate the signing key when it may be compromised or on an internal schedule (for example annually). Generate a new key pair, replace the T383838COSIGN_PRIVATE_KEY (and password) secret in Gitea, and replace T383838cosign.pub in the repository with the new public key. Releases built before rotation remain verifiable using the old public key kept alongside the download or in git history; document which key applies to which release tag if you maintain multiple keys.

Install cosign for bundle verification. You need the T383838cosign.pub file from the repository (same tag or T383838master as the release you are checking).

Each released file has a sidecar T383838filename.sha256 containing the output of T383838sha256sum (hex digest and filename). After downloading both files into the same directory:

T282828

On macOS without GNU coreutils, compare the printed digest to T383838shasum -a 256 your-artifact or use T383838openssl dgst -sha256 your-artifact.

From the repository root (so T383838scripts/ci/verify-release-attestation.sh resolves), or with T383838COSIGN_PUBLIC_KEY pointing at your copy of T383838cosign.pub:

T282828

This checks the signature and Rekor transparency-log inclusion for the attestation. If you intentionally use a private Sigstore deployment, set the same T383838COSIGN_REKOR_URL (and any other Sigstore env vars) your builder used.

Published images are built in T383838.gitea/workflows/docker.yml. OCI image cosign signing is not wired in that workflow yet. Until it is, treat digest pinning as the main integrity check: pull or reference the image by T383838@sha256:<digest> from a trusted manifest or registry UI, and optionally run T383838trivy image against that digest. When cosign image signing is added, verification will look like:

T282828

(Exact flags may depend on keyless versus key-based signing; follow the release notes when signing lands.)